Date: Thu, 15 Jul 93 04:30:02 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #208 

To: packet-radio 


Packet-Radio Digest Thu, 15 Jul 93 Volume 93 : Issue 208 


Today's Topics: 
HELP: Testing TCP/IP radio packets 
How to supress nodes bcast in G8BPQ 
MPF102 direct replacement ? 
NOS and Baycom 
Packet-Radio Digest V93 #207 
RTTY DECODING 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Tue, 13 Jul 1993 21:22:12 GMT 

From: lll-winken.1l1nl.gov!fastrac.1l1nl.gov!wsrcc.com!wetware!khijol! warrior! 
erc@ames.arpa 

Subject: HELP: Testing TCP/IP radio packets 

To: packet-radio@ucsd.edu 


Andy Micone (andym@inrird.com) wrote: 


Besides, you wouldn't believe how many so-called military "experts" have 
: told me lately "TCP/IP packets over radio, impossible!" ;) 


I already replied to you via email, but perhaps this is something that can 
be pass along to others. If you put your TNC in transparent mode, you can 
put pretty much whatever you like on top of AX.25 - uucp, slip, whatever. 
It's not the most efficient, but it saves writing drivers and software, 
and it easily interfaces with existing serial protocols. 


I'm writing this on a 386 notebook computer, linked with a 486/25 via 
two KPC-3 TNC's, an Icom P2AT HT and an Alinco DR-590 dual band radio. 
Linked via uucp. 
Ed Carp erc@wetware.com 510/659-9560 
For anonymous mailers --> anonymus+5300@charcoal.com 
"Disagreements are not meant to be challenges. They are just a different 
reality." -- Risa D'Angeles 


Date: 14 Jul 93 21:20:28 GMT 

From: news-mail-gateway@ucsd.edu 

Subject: How to supress nodes bcast in G8BPQ 
To: packet-radio@ucsd.edu 


In article <742404018snx@llondel.demon.co.uk> dave@llondel.demon.co.uk writes: 
>>The only way you can do this is to set the route quality between the two 
>>nodes to a low level. If you set the QUALITY to 10 and the MINQUAL to 10 
>>then you should get a situation where the two nodes know about each other 
>>but don't pass any other route info. You cn probably set both parameters 
>>to a higher (but equal) level if you want both your nodes to propagate past 
>>each other. 

>> 

>>Dave 


kilroy!gwalsh@jpl.nasa.gov (Gerry) replies: 
usc!elroy.jpl.nasa.gov!kilroy! gwalsh@ 


Hi Dave, 

> 

>That's what I thought. One thing about the QUALITY parameter confuses 
>me though. Does G8BPQ "de-rate" the quality of each individual node (as 
>provided by the broadcast from the node "up-stream") by a given amount? 
> 

>Lets say that some node sends out a NODES bcast and that a node called 
>MTNTOP has a quality of 40 (as passed to my node in the bcast). If my 
>QUALITY parameter for that port is set to, say 70 will the MTNTOP node (when 
>placed in *MY*x nodes table) have a QUALITY of 70? That would seem to 
>defeat the purpose of bcasting a QUALITY. My node should take the bcast 
>quality of 40 and de-reate it to something like 30 or less, shouldn't 
>it? 

> 

>The reason I ask is that I have tried (before using news) setting the 
>QUALITY of the port to 50 and the MINQUAL to 20. Only a xfewx nodes 
>made it through that filter. 


Hi Gerry, 


Let me quote to you out of the book: 


"For each destination node listed in the broadcast, an indirect route 
is assumed to exist via the node who originated the broadcast. 


The quality of this route is calculated combining the BROADCAST QUALITY 

with the CHANNEL QUALITY parameter appropriate to the channel over which 
the broadcast was received. The qualities are multiplied, normalized, 

and rounded as shown in the following formula:" 


Route Quality = (broadcast quality X channel quality + 128 


Thus what quality a node has and whether it appears on your list is a 
function of YOUR PORT quality and the quality your NEIGHBOR says it has 
assigned for the node your NEIGHBOR IS HEARING! 


A typical trick is to lower your PORT or HDLC quality to something around 

say 112, and then have a MIN QUAL to BROADCAST of say 108. This means that 
all nodes you hear DIRECTLY will have a quality of 112. The above formula 
does not come into play until you start dealing with what your NEIGHBOR hears 
and what of THAT you want to appear on your node list. 


The answer here is to then LOCK (manually enter and end with a !) the route 
quality to KNOWN GOOD NEIGHBORS! 


Now what defines a "Known good neighbor". Is it that you have a solid radio 
link to the guy? Yes.. that's true, or should be true, but it is not the 
end-all, do-all that the book tries to imply. Another consideration is 

DO YOU TRUST THE LIST THAT YOUR NEIGHBOR SAYS IT CAN GET 10????? This is 
the most IMPORTANT factor in assigning a manual route quality to a neighbor 
node! 


I.E. Let's say that you had a PORT (or HDLC) QUALITY of 112, and a MINQUAL 
to BROADCAST of 108, but then you MANUALLY entered a route quality to your 
neighbor of 192! This would in effect cause a lot of the nodes that your 
neighbor HEARD to appear on YOUR list, and not only that, what your 
NEIGHBORS NEIGHBOR HEARD TOO! By twiddling this manual ROUTE QUALITY for 
the specific neighbor node UP and DOWN in value, (while leaving PORT QUAL 
set low) you can then adjust whether you want to hear just what your 
neighbor is hearing DIRECT or what your neighbors NEIGHBOR hears too! 


The good thing is that by doing this, you will not pass on nodes that you 
hear during a bandopening! Remember, all the nodes you hear then will have 
the PORT (HDLC) quality of 112 and although they WILL be broadcast, your 


neighbor node sysop has a WIDE variation on what you have told him is 
"known good" and what you just happened to hear because the band was open. 
This is known as "route locking" and is the best way to go about setting 
up node automatic adaptive routing. 


It prevents your node from using a path to a node that was heard ona 
band opening, rather than a node that you know works ALL the time! 


Twiddling with the default PORT (HDLC) QUALITY and MIN TO BROADCAST (also 
sometimes called MIN TO UPDATE... as in..... "appear on your node list") 
affects EVERY NODE BROADCAST HEARD. Pick a starting point and then 
adjust your MANUAL route assignments to get what you want. 


Remember, as long as your node has a PORT (HDLC) QUALITY higher than your 
MIN to UPDATE, then it WILL send a node broadcast including all those 
nodes! Where you set the numbers to will influence whether your neighbor 
LISTS them, but not whether you BROADCAST them! 


If you want to limit BROADCAST SIZE, then simply have a PORT (HDLC) QUALITY 
*xLOWER*x than MINQUAL! This will stop your node from passing on ANY info 

it hears from ANYONE else except it's own identity. If you want to pass 

on known good routes only.. do the above and then simply MANUALLY lock the 
ROUTE QUALITY of SPECIFIC NEIGHBORS to a HIGHER number than MINQUAL! 


This method will stop BROADCASTS of ALL band opening nodes.. they will 
not appear on your node list, and they will not be broadcast to your 
neighbors. Pretty drastic action though. 


Remember, ROUTE LOCKING is *NOT*x the same as *NODE LOCKING*x. If you 
manually lock a route quality, it will not broadcast the existence of 
that node should it go away.. if you have locked the route quality and 
your neighbor node bites the dust, your node will know it, will not route 
to it, and will not broadcast its existence. 


Judging from what appears on most node lists, the above is the least 
understood aspect of a node by most sysops... it 1s confusing but once 
you lower PORT QUAL and MINQUAL and then manually LOCK neighbors to a 
higher value and watch what happens, you'll get the hang of it quickly. 


What I don't like about BPQ code is that apparently you can NOT lock a 
ROUTE QUALITY to a SPECIFIC NODE *xLOWER* than PORT QUALITY x*IFx the 
BPQ node is also hearing it DIRECTLY! This is a flaw in the code since 
it does not allow a sysop to lock one nodes total broadcasts OUT of your 
node. Regular "TheNet and NET/ROM" nodes allow this. 


Best of luck.. sorry for the length.. but it's hard to say in a few 
words with any real luck of getting the meaning across. 


Mark Bitterlich 
wa3jpy@wb4uou.#eastnc.nc.usa.noam 
mgb@tecnet1.jcte.jcs.mil 


Date: 14 Jul 93 18:44:48 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: MPF102 direct replacement ? 
To: packet-radio@ucsd.edu 


Hi packeteers .. 

Any idea for direct replacement of MPF 102 FET (motorola) 

for use in ARRL Handbook(s) projects ? 

I will appriciate e-mail answer. (some digests never arrived...) 


73 de George (SV3CHA) 


Date: Wed, 14 Jul 1993 03:19:38 GMT 

From: pravda.sdsc.edu!news.cerf.net!usc!cs.utexas.edu!swrinde! gatech!news- 
feed-2.peachnet.edu!news-feed-1.peachnet.edu!umn.edu!staff.tc.umn.edu! 
weiss@network.UCSD.EDU 

Subject: NOS and Baycom 

To: packet-radio@ucsd.edu 


I'm trying to get PAOGRI's NOS (NOSVIEW) running with a Tigertronics Baycom 
modem (TCM3105) and a laptop (xt) or 386. NO LUCK. Directories were 
unzipped OK with -d option, I THINK I'm set up, and I have been able to at 
least decode AX25 on the laptop. NOTHING on the 386 on com1 OR com2. 


Baycom 1.4 works OK, however. 


Any ideas? Has anyone got NOS working with a Baycom-type modem? ANy local 
contacts I can call? 

Thanks, 

Jeffrey Weiss NOIRR 


Date: 14 Jul 93 14:54:22 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: Packet-Radio Digest V93 #207 
To: packet-radio@ucsd.edu 


The gentleman that wanted a name of a Co that produced a TCP/IP pgm 
>>>>> FTP corp. is one. 


Go looking for the NCSA code at Clarkson University to FTP Free of 
Charge. 


Brad Clemmons is the author. 


Ken 


>>RVGC2@VTVM1.CC.VT.EDU<< 
>>PHONES 703-857-7584 >>VATECH CAMPUS 13855<< 
>>FAX 703-857-7371<< KEW6X@POE.ACC.VIRGINIA.EDU >> 
>>ARMY MARS AAT3PK/VA<< AMATEUR>N4LYO<< 
>>IBMMAIL (USVPITMA) << 
ROANOKE VALLEY GRADUATE CENTER 
US SNAIL: 117 W. CHURCH AVE. 
ROANOKE, VA. 24011-1905 


Date: 15 Jul 93 04:17:28 GMT 

From: mnemosyne.cs.du.edu!nyx! gbaron@uunet.uu.net 
Subject: RTTY DECODING 

To: packet-radio@ucsd.edu 


dts@banyan.com (Daniel Senie) writes: 


>In article <742093147snx@llondel.demon.co.uk>, dave@llondel.demon.co.uk 
David Hough) writes: 

>|> In article <742008561.AA05767@csource.oz.au> David.Simpson@£393.n632. 

3.fidonet.org (David Simpson) writes: 

>|> > I AM USING MFJ1278B WITH IBM 486SX, AND HAVING PROBLEMS DECODING 

>|> COMMERCIAL RTTY..ANY CLUES PLEASE? 

>|> 

>|> 

>|> 

3.0) 

>|> > 

>|> Are you using the correct tone shift? I think some commercial RTTY us 

Ss 

>|> a 425Hz shift. You also need to check whether it is running 45 or 50b 
ud 

>|> because that will screw your reception as well. Failing that, it migh 
be 

>|> scrambled in some way... 


> 
> 
> 
> 


* Origin: Spectrum Radio - Melbourne's All Band Radio BBS (3:632/3 


>|> 
>|> Dave 


>Amateur RTTY uses 170Hz shift, commercial uses 850 mostly. There are oth 
r odd 
>shifts in use as well... 


>|> 
>|> KEKKKKKKKKKKKKKKKKKKKKKKK KKK KKK KKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKE 
KKKKKKK 


>|> * G4WRW @ GB7WRW.#41.GBR.EU AX25 * You think xyoux have proble 

Ss? * 

>|> * dave@llondel.demon.co.uk Internet x* What do you do if you xare 
* 

>|> * g4wrw@g4wrw. ampr.org Amprnet x a manically depressed rob 

t?? * 


>|> KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
aKaKKKKKK 


>-- 

> weeeeeeenenene ene ew ewww ewww ewww ewww eww eww ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ee ew 
>Daniel Senie Internet: dts@questar.banyan.com 
>Banyan Systems, Inc. Compusetrve: 74176 ,1347 

>508-898-1188 Packet Radio: NIJEB@KA1SRD.MA 


This is a test post 


End of Packet-Radio Digest V93 #208 
KAKKKK KKK KKK KIKI KKK IKKE KER 


